The generic bootstrapping architecture (GBA) as specified e.g. in the third generation partnership project (3GPP) TS 33.220, version 12.0.0, is used for authenticating subscribers to a bootstrapping server in a network based on their subscription credentials, i.e. in the (universal) subscriber identity module ((U)SIM). The authentication results in a mutual authentication between the network and a mobile device/UE/terminal, and in that keys or credentials, are established between an application function and the mobile device.
FIG. 1 illustrates an exemplary GBA/GAA, with a NAF 1 connected to a BSF 3. A BSF and a user entity (UE) 2 mutually authenticates using the authentication and key agreement (AKA) protocol, and UE communicates with BSF over an interface Ub. The UE and a home subscriber system (HSS) shares a key that is a basis for HSS to generate an authentication vector provided to BSF over interface Zh. According to the AKA protocol, BSF sends to UE a challenge, and UE returns a response to BSF. The authentication is verified by BSF comparing the UE response with an expected response as provided by HSS. A successful authentication initiates at BSF and UE a generation of a shared key Ks. BSF stores the key Ks and associated reference bootstrapping transaction identifier (B-TID). The reference B-TID and other data, such as a key lifetime, are thereafter provided to UE in a completion message. A subscriber locator function (SLF) is queried by the BSF over interface Dz in conjunction with the Zh interface operation to get the name of the home subscriber server (HSS) containing the required subscriber-specific data. UE may connect simultaneously to at least one application server through a network application function (NAF) authentication proxy. The connection comprises a first step of authentication between UE and NAF. Thereby, UE provides the reference B-TID to NAF, which, using B-TID, requests a key, or credential, Ks_NAF, from BSF over interface Zn. The key Ks_NAF is derived from the key Ks. The same key or credential may be derived at UE. Authentication is thereafter performed, based on the derived key Ks_NAF. The communication between UE and NAF is over an interface Ua.
FIG. 2 illustrates GAA-related functionalities in a terminal, e.g. in the UE in FIG. 1 according to Trusted open platform specified e.g. in the TR 33.905, V11.0.0. The realization of the GBA in a terminal can be divided into a GAA server and GAA client, wherein the GAA server in the terminal is the counterpart of the BSF. The GAA server may also be referred to as a bootstrapping client, as indicated in FIG. 2, and the GAA client in the terminal is the counterpart of the NAF, and may also be referred to as an Application client; see FIG. 2.
Typically, the internal interfaces and the application programming interfaces (APIs) of the terminal are not standardized. Further, the bootstrapping client (GAA server) is a trusted element, which is trusted to perform bootstrapping and deriving NAF keys for all applications according to existing GBA functionality. The GAA server will hereinafter be referred to as a bootstrapping client. As illustrated in FIG. 2, the bootstrapping client communicates with the BSF over a Ub interface, and with a universal integrated circuit card (UICC) e.g. through relevant device drivers. The GAA client communicates over the network with the NAF and with the bootstrapping client in order to obtain the NAF-specific GAA credentials. When a NAF requests a GAA client to authenticate itself with GAA credentials, the GAA client communicates with the bootstrapping client for GAA credentials specific to that NAF.
However, in the case the terminal is a smartphone, and a parent for instance makes purchases with the smartphone from a web-shop that uses GBA for authentication, a child may accidentally make additional purchases from the web-shop, if the phone is available to the child, since the authentication has already succeeded, and the connection to the web-shop may still be alive. Thus, there is a need to improve the security.